|
Backscatter (also known as outscatter, misdirected bounces, blowback or collateral spam) is incorrect automated bounce messages sent by mail servers, typically as a side effect of incoming spam. Recipients of such messages see them as a form of unsolicited bulk email or spam since they were not solicited by the recipients, are substantially similar to each other and are delivered in bulk quantities. Systems that generate email backscatter can end up being listed on various DNSBLs and be in violation of internet service providers' Terms of Service. Backscatter occurs because worms and spam messages often forge their sender address, and a misconfigured mailserver which has DSN's enabled, send a bounce message to this address. This normally happens when a mailserver is configured to relay a message to an after-queue processing step, for example an antivirus scan or spam check, which then fails, and at the time the antivirus scan or spam check is done, the client has already disconnected. In those cases, it's normally not possible to reject at the SMTP stage, since a client would timeout waiting for the antivirus scan or spam check to finish. The best thing to do in this case, is then silently dropping the message, e.g. piping it to /dev/null. Measures to reduce the problem include avoiding the need for bounce message by doing most rejections at the initial SMTP connection stage; and for other cases, sending bounce messages only to addresses which can be reliably judged to have not been forged, and in those cases the sender cannot be verified, thus ignoring the message (dropping it). ==Cause== Authors of spam and viruses wish to make their messages appear to originate from a legitimate source to fool recipients into opening the message so they often use web-crawling software to scan usenet postings, message boards, and web pages for legitimate email addresses. Due to the design of SMTP mail, recipient mail servers receiving these forged messages have no simple standard way to determine the authenticity of the sender. If they accept the email during the connection phases then, after further checking refuse it - for example because they believe it to be spam they will use the (potentially forged) sender's address to attempt a good-faith effort to report the problem to the apparent sender. Mail servers can handle undeliverable messages in three fundamentally different ways: * Reject. A receiving server can reject the incoming email during the connection stage ''while the sending server is still connected''. If a message is rejected at connect time with a 5xx error code then the ''sending'' server can report the problem to the real sender cleanly. * Drop. A receiving server can initially accept the full message, but then determine that it is spam or virus, and then delete it automatically, sometimes by rewriting the final recipient to "/dev/null" or similar. This behavior can be used when the "spam score" of an email is seriously high or the mail contains a virus, even though RFC 5321 says: "''...silent dropping of messages should be considered only in those cases where there is very high confidence that the messages are seriously fraudulent or otherwise inappropriate...''" * Quarantine. A receiving server can initially accept the full message, but then determine that it is spam, and ''quarantine'' it - delivering to "Junk" or "Spam" folders from where it will eventually be deleted automatically. This is common behavior. * Bounce. A receiving server can initially accept the full message, but then determine that it is spam or to a non-existent recipient, and generate a bounce message back to the supposed sender indicating that message delivery failed. Backscatter occurs when the "bounce" method is used, and the sender information on the incoming email was that of an unrelated third party. 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「Backscatter (email)」の詳細全文を読む スポンサード リンク
|